Software  Acquisition 


Software  Acquisition  in  the  Army 


Elizabeth  Starrett 
Crosstalk 


There  has  been  much  discussion  lately  regarding  the  Global  War  on  Terror’s  (GWOT)  financial  ramifications  to  the  United 
States  Army.  While  all  of  the  Department  of  Defense  (DoD)  is  challenged  financially  during  the  ongoing  war,  the  Army 
appears  to  be  most  effected  [1,2].  As  CROSSTALK  prepared  this  issue  on  Software  Acquisition,  we  thought  CROSSTALK 
readers  would  benefit from  a  discussion  of  this  challenge,  providing  additional  perspectives  to  acquisition  efforts. 


CROSSTALK  contacted  representative 
Army  Program  Executive  Offices 
(PEOs)  that  deal  with  software  and  asked 
for  their  perspectives  on  several  acquisi¬ 
tion  topics.  We  received  responses  from 
the  following  five  PEOs  (see  the  sidebar 
on  page  5  for  a  brief  description  of  each): 
•  Ammunition. 

•  Command,  Control,  and  Commu- 
nications-Tactical  (C3T). 

•  Enterprise  Information  Services 

(» Is)- 

•  Future  Combat  Systems  Brigade 
Combat  Team  (FCS  BCT). 

•  Ground  Combat  Systems  (GCS). 

We  asked  each  of  them  the  same  five 
questions.  The  following  are  those  ques¬ 
tions  and  their  answers: 

QWhat  is  the  biggest  software 
»  acquisition  challenge  you 
are  currently  facing? 

Ammunition:  Our  biggest  challenge  is  to 
acquire  and  maintain  (throughout  the  life 
cycle)  safe,  reliable,  supportable,  and  mod¬ 
ifiable  systems  that  meet  user  requirements 
in  an  environment  of  rapid  technological 
advances  and  complex  regulations  and 
policies  which  are,  in  many  cases,  overly 
broad.  As  an  example,  information  assur¬ 
ance  (I A) -related  requirements  are  applica¬ 
ble  equally  to  all  systems  (business,  com¬ 
mand  and  control,  weapons  in  a  tactical 
environment,  etc.).  However,  due  to  the 
differing  operational  environments  and 
system  capabilities,  the  threats  and  vulner¬ 
abilities  for  business  systems,  command 
and  control  systems,  and  weapons  systems 
are  different,  and  the  use  of  broad  IA  reg¬ 
ulations  and  policies  can  create  additional, 
and  in  many  cases,  unnecessary  costs. 

C3T:  As  the  needs  of  our  warfighters  are 
rapidly  evolving  to  address  unique 
wartime  challenges,  the  process  for  insert¬ 
ing  software  enhancements  into  Programs 
of  Record  (PORs)  to  satisfy  these  new 
requirements  must  be  timely.  In  order  to 


meet  urgent  needs,  users  will  sometimes 
develop  home-grown  tools  and  software 
or  contract  developments  that  may  not 
fully  consider  the  implications  of  operat¬ 
ing  in  a  tactical  environment.  Any  fielded 
solution  needs  to  recognize  unique  tactical 
capability  demands,  such  as  the  need  for 
efficient  use  of  limited  tactical  bandwidth, 
interoperability  with  Army-provided  sys¬ 
tems,  and  long-term  sustainment,  as 
would  be  required  within  the  normal 
acquisition  process.  Our  challenge  is  to 
immediately  recognize  these  high-priority 
unit  needs,  fully  understand  and  document 
the  impacts,  and  drive  the  appropriate 
acquisition  approvals,  while  retaining  the 
warfighter’s  confidence  that  the  process 
can  respond  with  the  right  solution  at  the 
right  time.  Anything  that  can  be  done  to 
make  the  acquisition  process  more  timely 
and  efficient  contributes  greatly  to  mis¬ 
sion  success. 

EIS:  Clearly  our  greatest  challenge  is  help¬ 
ing  to  take  the  Army  Business  Mission 
Area  (BMA)  into  net-centric  operations 
and  warfare.  This  starts  with  Army 
Business  Transformation  and  the  efforts 
of  Mike  Kirby,  Deputy  Under  Secretary  of 
the  Army  Business  Transformation  and 
the  Lean  Six  Sigma  program.  It  makes 
sense  to  spend  the  time  necessary  to  lean 
out  our  business  processes  before  we  start 
buying  solutions.  As  a  matter  of  fact,  the 
new  solutions  we  need  to  be  net-centric 
fall  into  the  category  of  enterprise  solu¬ 
tions.  These  solutions  are  different  in  that 
they  are  transformational  in  nature  and 
present  a  whole  constellation  of  issues  we 
have  not  had  to  deal  with  in  the  past. 
Enterprise  Resource  Planning  (ERP)  and 
Service  Oriented  Architecture  (SOA)  are 
two  examples.  Both  require  a  massive 
amount  of  hard  work  in  the  functional 
community  before  implementation  of  any 
software  can  be  done  effectively  and  effi¬ 
ciently.  A  lot  of  hard  and  expensive 
lessons  have  been  learned  in  the  private 
sector  with  the  use  of  transformational 


Information  Technology  (IT).  We  do  not 
want  to  miss  any  of  these  lessons  as  we 
build  out  the  BMA.  We  have  noted  that 
most  of  the  failures  here  have  little  or 
nothing  to  do  with  technology.  The  fail¬ 
ures  involve  change  management,  gover¬ 
nance  and  policy,  and  decision  making,  as 
well  as  other  things  we  have  not  really 
dealt  with  before.  For  example,  in  an  SOA 
environment,  it  is  not  about  the  technolo¬ 
gy  as  much  as  it  is  about  the  way  you  do 
business  and  how  you  manage  the  tech¬ 
nology.  This  can  be  a  monumental  change 
for  any  organization,  and  an  absolute  if 
we  are  going  to  be  net-centric. 

FCS  BCT:  Our  biggest  challenge  is  the 
execution  of  the  FCS  BCT  program. 
Technical  complexity,  distributed  work¬ 
force,  the  use  of  commercial  off-the-shelf 
(COTS)  products,  complex  integration  of 
software  systems,  and  the  long-term 
schedules  required  for  ultra  large  software 
systems  present  a  significant  software 
acquisition  challenge. 

GCS:  One  of  our  biggest  challenges  is  the 
synchronization  of  multiple  sub- systems 
(including  their  support  software)  received 
from  various  contractors  and  other  gov¬ 
ernment  agencies.  The  Software  Blocking 
Initiative  was  supposed  to  ease  this  prob¬ 
lem,  but  software  synchronization  remains 
a  serious  challenge. 

Q|  How  is  the  GWOT 

»  affecting  your  organization? 

Ammunition:  The  GWOT  has  produced 
a  great  urgency  to  quickly  deliver  safe,  reli¬ 
able,  quality  systems  that  meet  users’ 
needs.  It  forces  a  focus  on  continual 
improvement  aimed  at  increasing  system 
operational  effectiveness  while  reducing 
overall  time  to  field.  This  is  not  a  trivial 
endeavor  given  the  increasing  complexity 
of  systems  and  software  and  the  compli¬ 
cated  regulations  and  policies  that  must  be 
adhered  to. 
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C3T:  The  GWOT  began  as  our  modern¬ 
ization  efforts,  initiated  as  part  of  Force 
XXI,  were  nearing  fruition.  It  quickly 
became  apparent  that  the  digital  battle 
command  software  tools  that  were  part  of 
that  initiative  would  become  a  decisive  ele¬ 
ment  of  the  fight.  In  a  brief  and  histori¬ 
cally  significant  period,  the  Army  went 
from  a  small  group  of  select  units  that 
experimented  with  digitization  to  a  fully 
interoperable  modular  force  operating  dig¬ 
ital  command  posts  and  related  systems. 
For  example,  our  Army  in  Iraq  today  oper¬ 
ates  from  a  common  operatingpicture  based  on 
Army  Battle  Command  System  (ABCS) 
Version  6.4.  That  common  operating  picture  is 
fed  into  our  Command  Post  of  the  Future 
which  allows  geographically  dispersed 
units  to  collaboratively  visualize  and  plan 
the  operational  battlespace.  Blue  force 
tracking  tracks  and  displays  our  platform 
locations  in  near  real-time  and  the  Joint 
Network  Node  connects  our  command 
posts  using  Internet  Protocol-based  satel¬ 
lite  communications  nodes.  As  the  systems 
engineer  involved  with  the  technical  chal¬ 
lenges  of  integrating  these  C3T  systems,  it 
is  hard  to  imagine  another  scenario  that 
would  have  had  more  of  an  impact  on 
how  PEO  C3T  operates.  The  GWOT 
sharpened  our  focus  on  the  task  at-hand, 
direct  support  to  the  warfighter,  while 
simultaneously  driving  groundbreaking 
work  that  transformed  our  tactical  IT. 

EIS:  GWOT  has  refocused  a  great  deal  of 
resources  and  that  means  schedules  slide 
to  the  right.  We  completely  understand  the 
constraints  that  everyone  has  to  absorb 
with  the  current  situation.  The  large  enter¬ 
prise  systems  acquisitions  by  their  very 
nature  are  resource  intensive. 

FCS  BCT:  The  GWOT  serves  to  refine 
the  picture  of  the  future  threat.  This  has 
highlighted  the  need  to  incrementally  field 
capability  to  the  current  force  to  help 
prosecute  the  GWOT.  Funding  the 
GWOT  has  resulted  in  funding  decre¬ 
ments  to  my  organization. 

GCS:  The  GWOT  has  had  a  significant 
impact  on  PEO  GCS.  Prior  to  the 
GWOT  or  Operation  Iraqi  Freedom 
(OIF),  the  Abrams  tank  program  and 
Bradley  vehicle  program  were  downsizing 
(due  to  large  funding  cuts  and  natural 
attrition  in  personnel)  in  anticipation  of 
new  FCS  vehicles  that  were  on  the  draw¬ 
ing  boards.  Since  the  GWOT  and  OIF, 
billions  of  extra  dollars  have  been 
pumped  into  Program  Manager  (PM) 
Heavy  Brigade  Combat  Team  to  modern¬ 
ize  these  existing  weapons  platforms  and 


U.S.  Army  Organization  Descriptions 

The  following  organizations  provided  feedback  to  the  questions  submitted: 
Ammunition  <http://peoammo.army.mil> 

The  mission  of  the  Ammunition  PEO  is  to  develop  and  procure  conventional  and  leap- 
ahead  munitions  to  increase  combat  power  to  warfighters.  The  PEO  has  been  delegated 
as  the  Single  Manager  for  Conventional  Ammunition  (SMCA)  mission  and  therefore  pro¬ 
cures  conventional  ammunition  items  that  have  been  transmitted  to  the  SMCA  for  services. 

Answers  provided  by  Robin  Gullifer,  Program  Executive  Office  Ammunition, 
Program  Management;  Heather  Vimba,  Program  Executive  Office,  Chief  Information 
Officer;  John  Scibilia  Armament  Research  Development  and  Engineering  Center 
Software  Engineering  Center. 

Command,  Control,  and  Communications  Tactical  (C3T) 
<http://peoc3t.monmouth.army.mil> 

The  mission  of  the  PEO  C3T  is  to  rapidly  develop,  field,  and  support  leading  edge,  sur- 
vivable,  secure  and  interoperable  tactical,  theater  and  strategic  command  and  control 
and  communications  systems  through  an  iterative,  spiral  development  process  that 
results  in  the  right  systems,  at  the  right  time  and  at  the  best  value  to  the  warfighter. 
Today  PEO  C3T  is  involved  in  critical  work  supporting  GWOT  efforts  through  fielding 
situational  awareness  systems.  These  systems  show  a  visual  representation  of  friend¬ 
ly  and  enemy  forces  on  computer  screens  inside  vehicles  and  command  posts  and 
help  to  prevent  fratricide  or  friendly  fire  incidents. 

Answers  provided  by  BG  Nickolas  G.  Justice,  Deputy  Program  Executive  Officer  C3T. 

Enterprise  Information  Services  (EiS)  <www.eis.army.mil> 

The  mission  of  the  EIS  PEO  is  to  provide  joint  service  and  Army  warfighters  with  infor¬ 
mation  dominance  by  developing,  acquiring,  integrating,  deploying,  and  sustaining 
network-centric  knowledge-based  IT  and  business  management  systems,  communi¬ 
cations  and  infrastructure  solutions  through  leveraged  commercial  and  enterprise 
capabilities  that  support  the  total  Army.  This  information  dominance  enables  the  Army 
to  achieve  victory.  PEO  EIS  develops,  acquires  and  deploys  tactical  and  non-tactical 
IT  systems  and  communications. 

Answers  provided  by  Dr.  Chip  Raymond,  Director,  Army  Enterprise  Solutions 
Competency  Center. 

Future  Combat  Systems  Brigade  Combat  Team  (FCS  BCT)  <www.army.mil/fcs> 
The  primary  mission  of  the  PM  FCS  BCT  is  to  develop,  produce  and  field  a  fully  capa¬ 
ble  and  sustainable  FCS  BCT  that  is  compliant  with  the  Joint  Requirements  Oversight 
Council  approved  Operational  Requirements  Document  by  the  year  201 4.  A  key  objec¬ 
tive  of  the  FCS  Program  is  to  successfully  develop  an  integrated  BCT  that  is  net-cen¬ 
tric,  lightweight,  overwhelmingly  lethal,  rapidly  deployable,  self-sustaining,  and  surviv- 
able.  The  FCS-equipped  BCT  will  be  enabled  by  a  fully  integrated  network  that  will 
increase  connectivity  and  intelligence  sharing  within  combat  formations,  while  provid¬ 
ing  unprecedented  situational  awareness  to  soldiers  in  the  field. 

Answers  provided  by  Edgar  L.  Dalrymple,  PM  FCS  BCT,  Associate  Director, 
Software  and  Distributed  Systems. 

Ground  Combat  Systems  (GCS)  <www.peogcs.army.mil> 

The  mission  of  GCS  is  to  maintain  a  total  Army  perspective  in  managing  the  develop¬ 
ment,  acquisition,  testing,  systems  integration,  product  improvement,  and  fielding  that 
places  the  best  ground  combat  and  support  systems  in  the  hands  of  our  soldiers.  They 
serve  as  the  System  of  Systems  Integrator  of  the  GCS  for  the  armed  forces  and  lead 
the  Army  transformation  toward  future  systems  as  they  evolve  to  the  objective  force 
while  maintaining  a  current  combat  ready  force.  Their  Abrams  tanks,  Bradley  Fighting 
Vehicles  and  Paladins  provide  battlefield  superiority  in  Iraq  .  The  Stryker  family,  the  Joint 
Lightweight  155mm  Howitzer  and  Unmanned  Ground  Vehicles  are  evolving  toward  the 
Stryker  and  Objective  Forces. 

Answers  provided  by  Mike  Olsem,  Senior  Systems  Engineer,  SAIC. 


enhance  crew  protection  from  enemy 
attacks.  This  has  created  some  (tempo¬ 
rary)  acquisition  and  engineering  staffing 
problems  due  to  a  shortage  of  experi¬ 
enced  personnel  (because  of  the  prior 
downsizing/ retirement  of  key,  experi¬ 
enced  personnel).  We  are  coping,  but 


everybody  is  extremely  busy. 

Q#  How  are  open  source 
•  software  and  open 
architectures  influencing 
your  acquisition  efforts? 


May  2007 


www.stsc.hill.af.mil  5 


Software  Acquisition 


Ammunition:  In  order  to  reduce  cost  and 
effort  for  compatibility,  we  make  extensive 
use  of  COTS  products  in  our  systems.  We 
have  only  just  begun  to  look  more  closely 
at  open  source  software  and  open  archi¬ 
tectures  to  determine  how  they  might  fit 
within  our  acquisition  of  systems.  The 
mission,  safety,  and  I A  critical  nature  of 
our  systems  weigh  heavily  in  determining 
what  COTS  products  and  open  source 
software  and  architectures  may  be  appro¬ 
priate  to  incorporate. 

C3T:  The  fundamental  concepts  behind 
open  source  software  and  open  architec¬ 
tures  have  driven  our  Battle  Command 
software  technical  vision  and  associated 
acquisition  efforts.  As  depicted  in  Figure 
1,  our  original  acquisition  efforts  focused 
on  satisfying  the  critical  subset  of  require¬ 
ments  for  high  intensity  conflict.  Building 
on  this  foundation,  we  opened  up  our 
architecture  by  implementing  a  common 
set  of  COTS /government  off-the-shelf 
services  across  our  tactical  operation  cen¬ 
ters  (Point  1  on  the  figure  represents  the 
Battle  Command  Common  Services 
[BCSS]  platform  for  distributing  services 
to  Battle  Command  users).  We  extended 
this  service  implementation  by  incorporat¬ 
ing  a  community  contribution  model  for 
the  development  of  Web  capabilities 
(Point  3  on  the  figure  represents  our 
Information  Management  [IM]  Frame¬ 
work).  By  incorporating  the  open  source 
model  and  an  open  architecture  as  depict¬ 
ed  in  the  figure,  we  have  improved  our 
acquisition  process  by  delivering  warfight¬ 
er-required  capabilities  and  partnering  with 


the  user  community  in  order  to  support 
requirements  for  full  spectrum  operations. 

The  important  part  of  our  IM 
Framework  is  that  the  applications  and 
Web  parts  can  then  be  managed  and  dis¬ 
tributed  to  the  community,  letting  the  sol¬ 
diers  get  back  to  doing  their  jobs  and  miti¬ 
gating  risk  described  in  the  first  question. 
Units  that  rotate  into  an  operational  theater 
occasionally  find  out  about  some  of  the 
tools  and  technology  developed  in-theater 
that  they  fall  in  on  only  after  they  deploy.  By 
adopting  the  IM  Framework,  we  facilitate 
the  timely  distribution  of  capabilities 
across  the  Army  so  that  the  generating 
force  can  assess  and  exercise  the  capabili¬ 
ties  being  used  by  deployed  units. 

EIS:  That  depends.  We  would  like  to  use 
more  of  these,  but  we  also  must  keep  in 
mind  that  security  is  a  critical  issue  for  us. 
We  think  that  the  Army  will  baseline  on  a 
federated  architecture  SOA.  SOA  is  all 
about  open  architecture  and  the  industry 
has  set  the  basic  standards  needed  to  make 
this  work  well.  We  have  security  concerns, 
however,  and  will  need  to  sort  though  that 
in  the  fullness  of  time.  It  would  be  nice  to 
use  open  source  stuff  but  we  need  to  be 
cautious. 

FCS  BCT:  The  FCS  BCT  program  devel¬ 
oped  its  most  foundational  software  com¬ 
ponent,  Systems  of  Systems  Common 
Operating  Environment  (SOSCOE),  to 
follow  the  design  principles  of  an  open 
architecture.  This  has  allowed  the  judi¬ 
cious  selection  and  use  of  many  COTS 
and  open  source  software  components. 


This  has  allowed  accelerated  development 
schedules  and  the  potential  migration  of 
SOSCOE  to  other  Army  systems,  repre¬ 
senting  an  opportunity  for  increased  inter¬ 
operability  and  war-fighting  capability. 

GCS:  No  effect  at  all  since  we  support 
highly  customized  weapons  platforms 
with  highly  customized  support  software. 
FCS  is  more  affected  than  we  are  as  they 
plan  future  weapons  systems  since  their 
stated  goal  is  to  make  more  usage  of 
COTS  and  open  architectures.  But  the 
Army  must  fight  with  what  we  have  and 
our  current  weapons  systems  do  not  use 
open  source  or  open  architectures. 

Q#  What  is  your  favorite 

•  government  acquisition 
success  story? 

Ammunition:  The  PM  for  Intelligent 
Munitions  System  made  a  decision  early  in 
the  contracting  process  to  maintain  a  mir¬ 
ror  software  support  environment  at  the 
Armament  Software  Engineering  Center 
and  to  require  periodic  software  drops  so 
the  Army  software  engineers  could  have 
better  insight  into  the  progress  being 
made  by  the  contractor,  allow  for  the  gov¬ 
ernment  to  conduct  independent  testing 
of  safety- critical  software,  and  to  ensure 
proper  transition  of  the  software  from 
development  to  maintenance.  This  mirror 
lab  is  currently  paying  additional  divi¬ 
dends.  It  will  be  used  to  speed  up  testing, 
thereby  reducing  overall  schedule. 

C3T:  Adaptability.  The  urgent  operational 
needs  from  our  OIF  and  Operation 
Enduring  Freedom  commanders  and  the 
Army’s  conversion  to  a  modular  force 
structure  meant  transitioning  developmen¬ 
tal  projects  into  widely  fielded  and  fully 
supported  systems  in  short  order.  Blue 
force  tracking,  the  Joint  Network  Node, 
and  Command  Post  of  the  Future  are  just 
a  few  examples  of  our  recent  successes  in 
making  that  happen.  Fundamentally,  dur¬ 
ing  wartime,  we  need  to  shift  our  mindset 
from  a  focus  on  ongoing  development  of 
our  major  PORs  to  a  focus  on  how  we  can 
meet  warfighter  needs  in  time  to  make  a 
positive  difference. 

EIS:  Army  General  Fund  Enterprise 
Business  System  (GFEBS).  Here  is  an 
example  of  a  transformational  technology 
being  applied  in  an  effective  and  efficient 
way.  Starting  at  the  very  top,  the  program 
has  the  complete,  dedicated  support  of 
the  functional  business  owner.  This  is  one 
of  those  lessons  learned.  If  the  business 


Figure  1 :  Satisfying  a  Critical  Subset  of  Requirements 

Adapting  to  Technology  and  Requirement  Change 


1 .  Align  with  industry  best  practices 
and  standards. 

2.  Adopt  proven  solutions  and  migrate 
from  there. 

3.  Use  Best  of  Breed  Web  technologies 
with  an  open  controlled  source  process 
to  enable  cross-development  between 
Units  and  PEO  C3T. 

4.  Continuous  engineering  using  adaptive 
processes  enabling  agile  technology 
insertion. 
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owners  do  not  support  a  transformational 
IT,  it  will  fail.  The  Army  financial  business 
owners  made  the  decision  early  on  to  put 
a  lot  of  effort  into  the  transformation. 
GFEBS  is  an  ERP,  which  comes  with  a 
host  of  best  business  practices.  This 
means  change  and  change  management. 
Although  GFEBS  is  early  in  its  acquisition 
cycle,  it  has  all  the  hallmarks  of  a  success¬ 
ful  transformational  technology  imple¬ 
mentation.  Since  there  are  no  lessons 
learned  with  the  second  kick  of  a  mule,  we 
have  learned  well. 

FCS  BCT:  SOSCOE  Make/Buy.  Per 
direction  of  the  Assistant  Secretary  of  the 
Army  (Acquisition,  Logistics  &  Technol¬ 
ogies),  the  FCS  BCT  program  instituted  a 
comprehensive  process  to  evaluate  COTS 
products  for  purchase  (buy),  versus  the 
development  (make)  of  custom  software 
products.  The  process  is  based  on  require- 
ments-driven,  markets  surveys,  and  life- 
cycle  cost/benefit  analysis.  There  are  mul¬ 
tiple  layers  of  management  review  that 
ensure  effective  technical  and  program 
management  oversight.  To  date,  this 
process  has  allowed  SOSCOE  to  be  devel¬ 
oped  from  approximately  80  percent 
COTS  software. 

GCS:  One  of  the  best  software  success 
stories  we  have  comes  from  the  Abrams 
System  Enhancement  Program  (SEP) 
tank.  Abrams  SEP  Version  1  tank  soft¬ 
ware  (using  circuit  boards  from  contractor 
A)  was  quickly  and  easily  ported  to  the 
Abrams  SEP  Version  2  tank  (using  circuit 
boards  from  contractor  B).  Using  a  soft¬ 
ware  development  approach  known  as  lay¬ 
ering  the  software ,  the  porting  of  software 
between  dissimilar  circuit  boards  was 
made  possible  by  isolating  the  software 
from  the  hardware  dependencies. 

Q#  If  you  could  make  one 
•  change  in  the  way  the 
government  procures 
software,  what  would  it 
be?  Why? 

Ammunition:  I  believe  we  actually  need 
to  work  on  two  changes: 

1 .  I  would  consolidate  and  simplify  regu¬ 
lations  and  policies  with  respect  to  soft¬ 
ware  acquisition  and  recommend  that 
Army  PMs  use  a  standard  acquisition 
process  model  such  as  the  Software 
Engineering  Institute  Capability  Ma¬ 
turity  Model  Integration  (CMMI®) 

®  CMMI  is  registered  in  the  U.S.  Patent  and  Trademark 
Office  by  Carnegie  Mellon  University. 


acquisition  model  that  is  due  to  be 
released  in  2007.  The  CMMI  acqui¬ 
sition  model  or  some  reasonable  alter¬ 
native  would  ensure  that  acquisition 
best  practices  are  used  for  procuring 
software-intensive  weapon  systems. 

2.  Ensure  that  software  centers  are 
involved  from  program  start  to  ensure 
the  RFP  and  Statement  of  Work  prop¬ 
erly  considers  software,  data  rights,  and 
software  supportability.  Too  often,  data 
rights  are  not  properly  considered  in 
the  solicitation  of  a  contract.  Without 
data  rights,  the  Army  is  accepting  the 
risk  of  not  being  able  to  support  its  sys¬ 
tem  if  the  contractor  goes  out  of  busi¬ 
ness,  changes  its  business,  or  defaults. 

This  over-reliance  on  a  single 
contractor  is  not  a  good  business  prac¬ 
tice  and  can  lead  to  cost  and  schedule 
overruns  or,  at  worst,  the  inability  to 
maintain  the  system  software. 

C3T:  It  is  hard  to  pick  just  one  as  we  have 

learned  so  many  lessons  over  the  last  20+ 

years  on  how  to  do  software  better.  So  I  will 

convey  my  top  three  interrelated  changes. 

1.  Acquisition  processes,  to  a  large 
degree,  are  driven  by  principles  estab¬ 
lished  to  acquire  and  manage  risks 
associated  with  the  acquisition  of  plat¬ 
forms/hardware.  Programs  are  funded 
as  new  platforms  with  unique  require¬ 
ments  to  be  tested  pass/fail.  The  focus 
is  on  up-front  risk,  to  get  it  right  the 
first  time,  prior  to  making  expensive 
production  decisions.  While  a  good 
model  for  platforms/hardware,  gener¬ 
ally  for  software  this  is  not  the  best 
approach.  And  increasingly,  more  sys¬ 
tems  are  becoming  software-intensive, 
if  not  wholly  software,  with  sought- 
after  warfighter  capabilities  that  are 
not  necessarily  new  or  unique,  but 
evolved.  Such  capabilities  would  be 
better  provided  (in  terms  of  cost, 
schedule,  and  risk)  as  integrated  pieces 
of  software  —  reused  where  possible. 
Software  is  really  a  continuous,  evolu¬ 
tionary  development  that  is  not  com¬ 
plete  until  a  system  is  retired.  And 
then,  much  of  the  software  should  be 
considered  for  reuse  on  the  replace¬ 
ment  system.  To  maximize  effective¬ 
ness,  the  acquisition  process  (and  life- 
cycle  model)  must  be  one  where  the 
Army  can  accept  software  as  is,  build 
on  it  incrementally  over  the  life  cycle, 
and  do  so  in  an  agile  manner. 

2.  We  need  to  use  a  more  holistic  strate¬ 
gy  (which,  by  the  way,  is  not  necessar¬ 
ily  supported  by  current  planning,  pro¬ 
gramming,  budgeting,  and  execution 
system  and  acquisition  policies/ 


processes).  That  is,  more  and  more 
sought  after  capabilities,  like  net-cen- 
tricity,  are  not  systems  but  are  con¬ 
cepts  implemented  through  numerous 
technologies,  systems,  and  supporting 
infrastructure.  Similarly,  related  fami¬ 
lies  of  systems  (system-of-systems) 
utilize  many  of  the  same/ similar  func¬ 
tions.  However,  we  keep  paying  for  the 
same/ similar  functions  to  be  built  over 
and  over.  By  taking  product  line 
approaches  and  leveraging  SOAs,  we 
can  build/buy  once,  centrally  manage 
the  software,  and  successfully  reuse 
these  software  assets.  These  approach¬ 
es,  when  implemented  well,  have 
proven  track  records  in  achieving  the 
better,  faster,  cheaper  objectives  we 
espouse  and  can  deliver  significant 
increases  in  return  on  investment.  This 
of  course  brings  certain  business  chal¬ 
lenges  such  as  incentivizing  industry  to 
reuse  rather  than  rebuild  and  would 
require  procurement  of  certain  essen¬ 
tial  government  rights,  source  code, 
and  supporting  documentation  from 
prime  contractors. 

3.  We  have  to  take  life-cycle  software 
management  seriously  (with  a  focus  on 
the  sustainment  phase).  In  recent 
industry  surveys,  we  have  validated  the 
fact  that  industry,  having  made  signifi¬ 
cant  investments  in  particular  software 
systems,  continuously  evolves  those 
systems  through  an  aggressive  soft¬ 
ware  sustainment  program,  ensuring 
that  a  system  continues  to  fulfill  its 
needs  over  time,  and  eliminating  need 
for  unnecessary  replacement  (sustain¬ 
ment  =  maintenance  +  moderniza¬ 
tion).  New  capabilities  (particularly 
software)  can  often  be  inserted  into 
current  systems  faster,  cheaper,  and 
with  less  risk  than  procuring  entirely 
new  systems  from  scratch.  System 
replacement  (new  development)  car¬ 
ries  a  high  risk  in  terms  of  time  and 
cost.  It  is  not  unusual  for  a  company  to 
expend  80  percent  of  a  software  sys¬ 
tem’s  life-cycle  cost  in  the  sustainment 
phase.  In  the  DoD,  we  typically  see  the 
reverse  (80  percent  through  produc¬ 
tion  and  only  20  percent  leveraging 
that  capability  investment).  All  of 
these  lessons  raise  the  fundamental 
question  that  must  be  addressed  for 
each  new  capability:  When  should  we 
procure  new  software  versus  evolve/ 
reuse  existing  software?  The  answer  to 
which  has  major  implications. 

EIS:  A  software  depot.  A  consolidated,  cen¬ 
tralized  store  for  Army  software.  One 

buyer,  one  seller.  Software  is  one  of  those 
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Coming  Events:  Please  submit  coming  events  that 
are  of  interest  to  our  readers  at  least  90  days 
before  registration.  E-mail  announcements  to: 
nicole.kentta@hill.af.mil. 


unique  commodities  that  ought  to  be 
managed  at  the  enterprise  level.  We  know 
this  and  we  are  moving  in  that  ultimate 
direction.  Once  we  have  the  depot  opera¬ 
tional,  we  will  have  a  reasonable  chance  to 
manage  software  like  we  do  repair  parts. 
There  must  be  a  lot  of  savings  with  that 
kind  of  approach. 

To  elaborate,  there  are  a  number  of 
ongoing  activities  that  aim  at  managing 
software  at  the  enterprise  level.  We  believe 
that  business  software  (that  is  the  func¬ 
tional,  network,  and  enterprise  software) 
and  IT  systems  could  be  managed  in  the 
same  way  as  we  successfully  manage  our 
logistics  base  in  the  Army.  The  highest 
value  target,  for  example,  could  be  cen¬ 
tralized  license  asset  management.  If  I 
know  where  all  the  licenses  are,  know 
where  they  are  needed,  and  know  what  is 
on  the  shelf  (you  cannot  scan  a  network 
to  locate  these),  then  I  think  I  could  cross¬ 
level  throughout  the  enterprise  and  drive 
down  the  total  cost  incurred  when  every¬ 
one  buys  their  own  licensed  software. 
With  the  maturing  capability  of  Web  2.0 
and  software  as  a  service ,  we  will  one  day  be 
able  look  across  the  enterprise  and  see 
where  our  assets  are  being  used  and  better 
manage  them.  That  is  a  long  way  off. 
There  are  a  lot  of  early  efforts  under  way 
to  do  centralized  management.  In  this  era 
of  constrained  budgets,  it  might  make 
sense  to  increase  our  focus  in  this  area.  It 
is  just  good  business  to  do  this  and  see 
how  much  money  we  can  really  save. 

FCS  BCT:  The  government,  at  least  the 
Army,  needs  to  stop  buying  software 
exclusively  from  the  traditional  defense 
contracting  base.  These  companies  have 
the  overhead  costs  of  manufacturing 
companies,  yet  software  development 
should  carry  a  far  smaller  overhead  bur¬ 
den.  Most  defense  contractors  are  still 
managed  by  manufacturing  engineers  or 
business  managers.  Very  few  of  them  have 
software  management  expertise.  By  using 
software-only  suppliers  who  have  relevant 
domain  experience  and  lower-cost  gov¬ 
ernment  labs,  the  cost  of  software  can  be 
reduced.  This  is  especially  true  now  that 
the  hardware  used  by  these  systems  is 
becoming  more  standard  off-the-shelf 
types  of  technologies. 

GCS:  For  our  major  weapons  systems,  we 
typically  do  not  procure  software.  Instead, 
we  procure  systems  and  subsystems  which 
contain  software.  However,  we  recognize 
that  software  is  a  critical  component  to  the 
modern  tanks,  cannons,  and  troop  trans¬ 
port  vehicles  (Bradley  and  Stryker).  Thus, 
we  would  like  more  emphasis  on  a  better, 


more  formal,  and  documented  process  for 
integrating  software  upgrades  into  existing 
platforms  (refer  to  the  software  synchro¬ 
nization  problems  in  the  first  question). 

Summary 

As  I  considered  the  responses  to  the  ques¬ 
tions  provided,  I  was  struck  by  the  contrast 
of  diversity  and  similarities  in  the  answers 
provided  by  the  PEOs.  For  example,  while 
addressing  the  what  is  the  biggest  software  acqui¬ 
sition  challenge  you  are  currently  facing  question, 
the  challenges  mentioned  ranged  from 
technical  challenges  to  business  process 
issues  and  combinations  of  both.  The  crit¬ 
icism  of  the  Software  Blocking  policy 
struck  me  because  I  have  heard  this  criti¬ 
cism  from  multiple  organizations. 

In  the  second  question  how  is  the 
GWOT  affectingyour  organisation ,  one  orga¬ 
nization  is  delivering  systems  more  quick¬ 
ly  while  another’s  schedules  are  sliding. 
One  PEO  is  dealing  with  a  decrease  in 
funding  while  another  is  dealing  with 
increased  funding.  Clearly,  the  GWOT  is 
delivering  a  major  impact  on  all  of  the 
organizations,  and  that  impact  appears  to 
be  dependent  on  how  close  the  product  — 
specific  to  each  PEO  -  is  to  the  fight. 
Easily  assumed,  all  of  the  PEOs  are  busier 
due  to  the  on-going  GWOT. 

Among  the  PEOs,  there  seems  to  be  a 
growing  acceptance  to  open  source  software 
and  COTS  products  over  time.  While  secu¬ 
rity  still  weighs  into  these  decisions,  organi¬ 
zations  focusing  on  new  acquisitions  are 
considering  the  potential  benefits  of  COTS 
and  open  source  options  more  readily. 

I  was  especially  eager  to  read  about  the 
success  stories  from  the  PEOs.  The  sto¬ 
ries  discuss  acquisition  methodologies  that 
look  outside  the  box  and  have  subse¬ 
quently  gotten  greater  value,  through 
inventive  means,  for  the  taxpayer. 

As  we  conclude  with  requests  for 
change,  most  of  the  PEOs  suggest  ideas 
that  will  simplify  and  consolidate  the 
acquisition  process.  Hopefully,  by  sharing 
this  acquisition  information,  the  PEOs’ 
requests  for  change  will  be  categorized 
beneath  the  success  stories  of  the 
future.  ♦ 
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